Spiral2 Control Command: a Standardized Interface between High Level Applications and Epics Iocs

The SPIRAL2 linear accelerator [1] will produce entirely new particle beams enabling exploration of the boundaries of matter. Coupled with the existing GANIL machine this new facility will produce light and heavy exotic nuclei at extremely high intensities. The field deployment of the Control System relies on Linux PCs and servers, VME VxWorks crates and Siemens PLCs; equipment will be addressed either directly or using a Modbus/TCP field bus network. Several laboratories are involved in the software development of the control system. In order to improve efficiency of the collaboration, a special care is taken to the software organization. During the development phase, in a context of tough budget and time constraint, this really makes sense, but also for the exploitation of the new machine, it helps us to design a control system that will require as little effort as possible for maintenance and evolution. The major concepts of this organization are the choice of EPICS, the definition of an EPICS directory tree specific to SPIRAL2, called "topSP2", this is our reference work area for development, integration and exploitation, and the use of version control system (SVN) to store and share our developments independently of the multi-site dimension of the project. The next concept is the definition of a “standardized interface” between high level applications programmed in Java and EPICS databases running in IOCs. This paper relates the rational and objectives of this interface and also its development cycle from specification using UML diagrams to test on the actual equipment. INTRODUCTION The Spiral2 Control System is designed with a typical EPICS architecture, relying on OPI Clients and IOC servers communicating using Channel Access (CA) protocol. Figure 1: Spiral2 Control System Architecture. The CA protocol allows OPI to read, write and monitor variables called Process Variables (PV) located in IOC. The CA protocol enable any OPI to access any PV as soon as it knows the PV name, there’s no need to know which IOC hosts the PV. OPI issues CA requests to IOC, which eventually interact with equipment to perform the actual read or write operation. This is the mean by which, over CA, functions are provided to OPI to fulfil its control tasks. Hence, OPI need to know the names of the PV that correspond to its purposes. This can quickly become a big mess on OPI side since there are many type equipment to be driven and each developer could to adopt its own philosophy on both OPI and IOC sides. It then appeared obvious that design should be optimized in order to reduce the development effort, but also in the machine exploitation perspective, to be able to face the evolution and maintenance requirements with a small team. Consequently, the decision was made to homogenize the way OPI control the various equipments through PV. So, starting from the fact that PV names are almost completely determined by the naming convention, which take into account the localisation and the type of equipment [2], and the observation that equipment driving is always achieved through same kind of functions, we started to glimpse the standard interface concept in the sense that the naming convention should be pushed one step further in order to codify the remaining part of the PV name in correlation with the expected function. This paper explains how the Standard Interface specifies the naming of the PV through which functions are provided to OPI, how it has been implemented on EPICS Data Base side (DB) and the first feedback is presented and next steps are envisaged. SPECIFICATION OF THE STANDARD INTERFACE